Home Blog About Me Resume

Policy Based Routing and Route Maps Under The Hood CCNP Notes

PBR Purpose

Policy-Based Routing (PBR) exists to give you control beyond normal destination-based routing. In traditional routing, a router looks only at the destination IP address, checks the routing table, and forwards the packet based on the best match. That works most of the time, but sometimes the “best” path according to the routing table is not the path you actually want traffic to take.

Override Destination-Based Routing

PBR allows you to override destination based routing decisions. Instead of forwarding traffic strictly based on the routing table, you can define policies that change how specific traffic is handled. If traffic matches certain criteria, the router can forward it differently than what the routing table would normally dictate.

Routing protocols focus on metrics and reachability.
PBR focuses on business intent.

Policy Decision Based on Packet Attributes

With PBR, forwarding decisions can be based on packet attributes such as:

  • Source IP address
  • Destination IP address
  • Protocol type
  • TCP/UDP port numbers

This means you are not limited to just where traffic is going you can also consider:

  • Who sent it
  • What type of traffic it is
  • How important it is

That flexibility is what makes PBR powerful.

Used for Traffic Steering, Not Path Discovery

The most important concept is this:

PBR is used for traffic steering not path discovery.

Dynamic routing protocols (OSPF, EIGRP, BGP) are responsible for discovering networks and calculating the best path. PBR does not influence how routes are learned or installed in the routing table.

Instead, PBR operates locally on the router and selectively overrides the routing decision for matched traffic.

Common use cases:

  • Sending VoIP traffic over a low-latency link
  • Forcing guest traffic out a secondary ISP
  • Directing specific subnets through a firewall or IDS

PBR Components

To understand Policy-Based Routing (PBR), you need to clearly understand its core building blocks. PBR is not complicated but each component has a specific role.

1. Access Control List (ACL) – Traffic Classification

The ACL identifies which traffic should be evaluated by the policy.

This is not for filtering or blocking traffic.
It is used to match traffic.

Examples of what an ACL can match:

  • Source IP address
  • Destination IP address
  • Protocol (TCP, UDP, ICMP)
  • Port numbers

The ACL answers the question:

What traffic are we making a special decision about?

2. Route Map – Policy Logic

The route map defines what action to take when traffic matches the ACL.

This is where the actual policy decision happens.

Common PBR actions include:

  • Set next-hop IP address
  • Set exit interface
  • Set default next-hop
  • Set IP precedence / DSCP (in some designs)

The route map ties the match condition (ACL) to the action (set statement).

The route map answers the question:

What should happen to this traffic?

3. Interface Command – Where It Is Applied

PBR is applied inbound on an interface.

Example logic:

  • Packet enters interface
  • Route map is evaluated
  • If matched → policy action is taken
  • If not matched → normal routing occurs

This is critical:

PBR must be applied to an interface to take effect.

Without applying the route-map to an interface, nothing happens.

Summary

PBR consists of three main components:

  1. ACL → identifies traffic
  2. Route-map → defines action
  3. Interface command → activates policy

ACL = Match
Route-map = Decision
Interface = Enforcement

That is the full PBR workflow.

Route Map Behavior

Understanding route map behavior is critical for PBR. The logic is sequential and deterministic.

Sequence Numbers Matter

Route-maps are processed top-down by sequence number.

  • The router checks sequence 10
  • If no match, it moves to sequence 20
  • Then 30, and so on

The first matching sequence is applied.
Once matched, processing stops.

There is no “best match” logic like routing tables.
It is strictly first-match wins.

Match and Set Logic

Each route-map entry can contain:

  • match statements
  • set statements

The logic works like this:

If the match condition is true → apply the set action.
If the match condition is false → move to the next sequence.

If a sequence has no match statement, it matches all traffic.

Implicit Deny

Route-maps have an implicit deny at the end.

If traffic does not match any sequence:

  • No policy is applied
  • Normal routing table lookup occurs

In PBR, this does not drop the packet.
It simply means “do nothing special.”

Permit vs Deny in PBR

In PBR specifically:

  • permit → apply the set action
  • deny → skip policy and use normal routing

This is different from ACL behavior, where deny drops traffic.

For PBR, a deny statement does not drop packets.
It just prevents policy from being applied.

Summary

Route-maps in PBR are:

  • Sequential
  • First-match wins
  • Implicit deny at the end
  • Permit = apply policy
  • Deny = normal routing

Core Set Actions

In PBR, the set statements define what happens to traffic after it matches the route-map.

1. set ip next-hop

This is the most common PBR action.

It tells the router to forward matching traffic to a specific next-hop IP address, overriding the routing table decision.

Example logic:

  • Traffic matches ACL
  • Route map matches
  • Router forwards packet to defined next-hop

If that next-hop is reachable, it will be used even if the routing table prefers something else.

2. set interface

This forces traffic out a specific exit interface.

Instead of specifying a next-hop IP, you specify the outbound interface.

This is simpler but less flexible than set ip next-hop, and it can cause issues on multi-access networks if not used carefully.

4. set ip precedence / set dscp (Policy Use Cases)

While not strictly forwarding actions, these can be used alongside PBR to influence QoS handling.

They modify packet marking rather than the path itself.

Failover Behavior (Basic)

Understanding failover behavior in PBR is important because PBR does not automatically provide intelligent failover like dynamic routing protocols do.

PBR is policy-driven, not topology aware.

What Happens If the Next-Hop Fails?

If you configure:

  • set ip next-hop X.X.X.X

The router will attempt to forward matching traffic to that next-hop.

If the next-hop is unreachable at Layer 3 (no route to it), the router will fall back to normal routing table behavior.

However, if the next-hop is reachable in the routing table but the path beyond it is broken, PBR will still send traffic there. It does not verify end-to-end reachability.

This is a common misconception.

Multiple Next-Hops

You can configure multiple next-hops in a single set statement.

The router will attempt them in order.

If the first next-hop is unreachable, it will try the next one in the list.

This provides basic conditional failover.

set ip default next-hop Behavior

set ip default next-hop behaves differently.

It is only used if there is no matching route in the routing table.

If a route exists, even if it is not ideal, the routing table wins.

PBR vs Dynamic Routing

Dynamic routing protocols:

  • Detect failures
  • Recalculate paths
  • Converge automatically

PBR:

  • Follows configured policy
  • Does not perform path calculation
  • Does not track remote path health by default

PBR is static logic applied to matching traffic.

Summary

Basic failover rules:

  • If next-hop is unreachable → normal routing may occur
  • Multiple next-hops can provide ordered fallback
  • No automatic convergence like routing protocols

PBR enforces policy.

It does not replace dynamic routing intelligence.

Verification Commands

After configuring PBR, it is essential to verify that policies are working as intended. You should focus on commands that show both the route-map application and the effect on traffic.

1. Show Route-Map Applied

show route-map

  • Displays all route-maps on the router
  • Shows sequence numbers, match criteria, and set actions
  • Useful to confirm the policy is correctly configured

2. Show IP Policy

show ip policy

  • Shows which route-maps are applied to which interfaces
  • Confirms inbound interface configuration

3. Show Access-Lists

show access-lists

  • Ensures ACLs referenced in the route-map match the intended traffic
  • Verifies correct source/destination, protocol, and port numbers

4. Show IP Route / Ping Tests

  • Use ping or traceroute to verify traffic follows the expected path
  • Use show ip route to understand fallback behavior if PBR fails
  • Optional: use extended ping to test from specific source addresses

5. Debug Commands (Optional / Lab Use)

debug ip policy

  • Provides real-time packet processing information
  • Only use in labs or controlled environments
  • Can overwhelm a production router if used carelessly

Design Warnings

When using PBR, there are several important design considerations to avoid issues in production networks. Understanding these warnings can save you from common pitfalls.

1. PBR Overrides Routing Table

  • PBR takes precedence over normal destination-based routing.
  • Misconfigured policies can send traffic down suboptimal paths or even into black holes.
  • Always verify ACL matches and next-hop reachability.

2. Performance Impact

  • PBR is applied per-packet on ingress.
  • High-volume traffic can consume CPU resources.
  • Avoid applying complex route-maps on high-throughput interfaces in production unless hardware supports it.

3. Limited Scope

  • PBR is ingress-only.
  • Does not apply to locally generated traffic unless specifically configured.
  • Must be applied per interface no global enforcement.

4. Failover Limitations

  • PBR does not provide dynamic failover.
  • If a next-hop is unreachable, traffic may fallback to the routing table or be dropped depending on configuration.
  • Multiple next-hops provide basic fallback but do not replace dynamic routing.

5. Troubleshooting Complexity

  • Misapplied PBR can make troubleshooting difficult because traffic may not follow the routing table.
  • Always verify with show ip policy, show route-map, and packet testing (ping/traceroute).

Summary

  • Use PBR only when necessary for traffic steering.
  • Keep policies simple and clear.
  • Always consider performance, scope, and failover limitations.

PBR is powerful, but with great power comes the need for careful design.